Long Term Evolution (LTE)
Third-generation mobile systems (3G) based on WCDMA radio-access technology is being deployed on a broad scale all around the world. A first step in enhancing or evolving this technology entails introducing High-Speed Downlink Packet Access (HSDPA) and an enhanced uplink, also referred to as High Speed Uplink Packet Access (HSUPA), giving a radio access technology that is highly competitive.
In order to be prepared for further increasing user demands and to be competitive against new radio access technologies, 3GPP introduced a new mobile communication system which is called Long Term Evolution (LTE). LTE is designed to meet the carrier needs for high speed data and media transport as well as high capacity voice support for the next decade. The ability to provide high bit rates is a key measure for LTE.
The work item (WI) specification on Long-Term Evolution (LTE) called Evolved UMTS Terrestrial Radio Access (UTRA) and UMTS Terrestrial Radio Access Network (UTRAN) is finalized as Release 8 (LTE Rel. 8). The LTE system represents efficient packet-based radio access and radio access networks that provide full IP-based functionalities with low latency and low cost. In LTE, scalable multiple transmission bandwidths are specified such as 1.4, 3.0, 5.0, 10.0, 15.0, and 20.0 MHz, in order to achieve flexible system deployment using a given spectrum. In the downlink, Orthogonal Frequency Division Multiplexing (OFDM) based radio access was adopted because of its inherent immunity to multipath interference (MPI) due to a low symbol rate, the use of a cyclic prefix (CP) and its affinity to different transmission bandwidth arrangements. Single-carrier frequency division multiple access (SC-FDMA) based radio access was adopted in the uplink, since provisioning of wide area coverage was prioritized over improvement in the peak data rate considering the restricted transmit power of the user equipment (UE). Many key packet radio access techniques are employed including multiple-input multiple-output (MIMO) channel transmission techniques and a highly efficient control signaling structure is achieved in LTE Rel. 8/9.
LTE Architecture
The overall architecture is shown in FIG. 1 and a more detailed representation of the E-UTRAN architecture is given in FIG. 2. The E-UTRAN consists of an eNodeB, providing the E-UTRA user plane (PDCP/RLC/MAC/PHY) and control plane (RRC) protocol terminations towards the user equipment (UE). The eNodeB (eNB) hosts the Physical (PHY), Medium Access Control (MAC), Radio Link Control (RLC) and Packet Data Control Protocol (PDCP) layers that include the functionality of user-plane header-compression and encryption. It also offers Radio Resource Control (RRC) functionality corresponding to the control plane. It performs many functions including radio resource management, admission control, scheduling, enforcement of negotiated uplink Quality of Service (QoS), cell information broadcast, ciphering/deciphering of user and control plane data, and compression/decompression of downlink/uplink user plane packet headers. The eNodeBs are interconnected with each other by means of the X2 interface.
The eNodeBs are also connected by means of the S1 interface to the EPC (Evolved Packet Core), more specifically to the MME (Mobility Management Entity) by means of the S1-MME and to the Serving Gateway (SGW) by means of the S1-U. The S1 interface supports a many-to-many relation between MMEs/Serving Gateways and eNodeBs. The SGW routes and forwards user data packets, while also acting as the mobility anchor for the user plane during inter-eNodeB handovers and as the anchor for mobility between LTE and other 3GPP technologies (terminating S4 interface and relaying the traffic between 2G/3G systems and PDN GW). For idle state user equipments, the SGW terminates the downlink data path and triggers paging when downlink data arrives for the user equipment. It manages and stores user equipment contexts, e.g. parameters of the IP bearer service, network internal routing information. It also performs replication of the user traffic in case of lawful interception.
The MME is the key control-node for the LTE access-network. It is responsible for idle mode user equipment tracking and paging procedure including retransmissions. It is involved in the bearer activation/deactivation process and is also responsible for choosing the SGW for a user equipment at the initial attach and at time of intra-LTE handover involving Core Network (CN) node relocation. It is responsible for authenticating the user (by interacting with the HSS). The Non-Access Stratum (NAS) signaling terminates at the MME and it is also responsible for generation and allocation of temporary identities to user equipments. It checks the authorization of the user equipment to camp on the service provider's Public Land Mobile Network (PLMN) and enforces user equipment roaming restrictions. The MME is the termination point in the network for ciphering/integrity protection for NAS signaling and handles the security key management. Lawful interception of signaling is also supported by the MME. The MME also provides the control plane function for mobility between LTE and 2G/3G access networks with the S3 interface terminating at the MME from the SGSN. The MME also terminates the S6a interface towards the home HSS for roaming user equipments.
Component Carrier Structure in LTE (Release 8)
The downlink component carrier of a 3GPP LTE (Release 8 and further) is subdivided in the time-frequency domain in so-called subframes. In 3GPP LTE (Release 8 and further) each subframe is divided into two downlink slots as shown in FIG. 3, wherein the first downlink slot comprises the control channel region (PDCCH region) within the first OFDM symbols. Each subframe consists of a give number of OFDM symbols in the time domain (12 or 14 OFDM symbols in 3GPP LTE, Release 8 and further), wherein each OFDM symbol spans over the entire bandwidth of the component carrier. The OFDM symbols thus each consists of a number of modulation symbols transmitted on respective NRBDL×NscRB subcarriers as also shown in FIG. 4.
Assuming a multi-carrier communication system, e.g. employing OFDM, as for example used in 3GPP Long Term Evolution (LTE), the smallest unit of resources that can be assigned by the scheduler is one “resource block”. A physical resource block (PRB) is defined as NsymbDL consecutive OFDM symbols in the time domain (e.g. 7 OFDM symbols) and NscRB consecutive subcarriers in the frequency domain as exemplified in FIG. 4 (e.g. 12 subcarriers for a component carrier). In 3GPP LTE (Release 8), a physical resource block thus consists of NsymbDL×NscRB resource elements, corresponding to one slot in the time domain and 180 kHz in the frequency domain (for further details on the downlink resource grid, see for example 3GPP TS 36.211, “Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation (Release 8)”, section 6.2, available at http://www.3gpp.org and incorporated herein by reference).
One subframe consists of two slots, so that there are 14 OFDM symbols in a subframe when a so-called “normal” CP (cyclic prefix) is used, and 12 OFDM symbols in a subframe when a so-called “extended” CP is used. For sake of terminology, in the following the time-frequency resources equivalent to the same NscRB consecutive subcarriers spanning a full subframe is called a “resource block pair”, or equivalent “RB pair” or “PRB pair”.
The term “component carrier” refers to a combination of several resource blocks in the frequency domain. In subsequent releases of LTE, the term “component carrier” is no longer used; instead, the terminology is changed to “cell”, which refers to a combination of downlink and optionally uplink resources. The linking between the carrier frequency of the downlink resources and the carrier frequency of the uplink resources is indicated in the system information transmitted on the downlink resources.
Similar assumptions for the component carrier structure apply to later releases too.
Logical and Transport Channels
The MAC layer provides a data transfer service for the RLC layer through logical channels. Logical channels are either Control Logical Channels which carry control data such as RRC signalling, or Traffic Logical Channels which carry user plane data. Broadcast Control Channel (BCCH), Paging Control channel (PCCH), Common Control Channel (CCCH), Multicast Control Channel (MCCH) and Dedicated Control Channel (DCCH) are Control Logical Channels. Dedicated Traffic channel (DTCH) and Multicast Traffic Channel (MTCH) are Traffic Logical Channels.
Data from the MAC layer is exchanged with the physical layer through Transport Channels. Data is multiplexed into transport channels depending on how it is transmitted over the air. Transport channels are classified as downlink or uplink as follows. Broadcast Channel (BCH), Downlink Shared Channel (DL-SCH), Paging Channel (PCH) and Multicast Channel (MCH) are downlink transport channels, whereas the Uplink Shared Channel (UL-SCH) and the Random Access Channel (RACH) are uplink transport channels.
A multiplexing is then performed between logical channels and transport channels in the downlink and uplink respectively.
Layer 1/Layer 2 (L1/L2) Control Signaling
In order to inform the scheduled users about their allocation status, transport format and other data-related information (e.g. HARQ information, transmit power control (TPC) commands), L1/L2 control signaling is transmitted on the downlink along with the data. L1/L2 control signaling is multiplexed with the downlink data in a subframe, assuming that the user allocation can change from subframe to subframe. It should be noted that user allocation might also be performed on a TTI (Transmission Time Interval) basis, where the TTI length can be a multiple of the subframes. The TTI length may be fixed in a service area for all users, may be different for different users, or may even by dynamic for each user. Generally, the L1/2 control signaling needs only be transmitted once per TTI. Without loss of generality, the following assumes that a TTI is equivalent to one subframe.
The L1/L2 control signaling is transmitted on the Physical Downlink Control Channel (PDCCH). A PDCCH carries a message as a Downlink Control Information (DCI), which in most cases includes resource assignments and other control information for a mobile terminal or groups of UEs. In general, several PDCCHs can be transmitted in one subframe.
It should be noted that in 3GPP LTE, assignments for uplink data transmissions, also referred to as uplink scheduling grants or uplink resource assignments, are also transmitted on the PDCCH.
Generally, the information sent on the L1/L2 control signaling for assigning uplink or downlink radio resources (particularly LTE(-A) Release 10) can be categorized to the following items:                User identity, indicating the user that is allocated. This is typically included in the checksum by masking the CRC with the user identity;        Resource allocation information, indicating the resources (Resource Blocks, RBs) on which a user is allocated. Note, that the number of RBs on which a user is allocated can be dynamic;        Carrier indicator, which is used if a control channel transmitted on a first carrier assigns resources that concern a second carrier, i.e. resources on a second carrier or resources related to a second carrier;        Modulation and coding scheme that determines the employed modulation scheme and coding rate;        HARQ information, such as a new data indicator (NDI) and/or a redundancy version (RV) that is particularly useful in retransmissions of data packets or parts thereof;        Power control commands to adjust the transmit power of the assigned uplink data or control information transmission;        Reference signal information such as the applied cyclic shift and/or orthogonal cover code index, which are to be employed for transmission or reception of reference signals related to the assignment;        Uplink or downlink assignment index that is used to identify an order of assignments, which is particularly useful in TDD systems;        Hopping information, e.g. an indication whether and how to apply resource hopping in order to increase the frequency diversity;        CSI request, which is used to trigger the transmission of channel state information in an assigned resource; and        Multi-cluster information, which is a flag used to indicate and control whether the transmission occurs in a single cluster (contiguous set of RBs) or in multiple clusters (at least two non-contiguous sets of contiguous RBs). Multi-cluster allocation has been introduced by 3GPP LTE-(A) Release 10.        
It is to be noted that the above listing is non-exhaustive, and not all mentioned information items need to be present in each PDCCH transmission depending on the DCI format that is used.
Downlink control information occurs in several formats that differ in overall size and also in the information contained in its fields. The different DCI formats that are currently defined for LTE are as follows and described in detail in 3GPP TS 36.212, “Multiplexing and channel coding”, section 5.3.3.1 (available at http://www.3gpp.org and incorporated herein by reference). For further information regarding the DCI formats and the particular information that is transmitted in the DCI, please refer to the technical standard or to LTE—The UMTS Long Term Evolution—From Theory to Practice, Edited by Stefanie Sesia, Issam Toufik, Matthew Baker, Chapter 9.3, incorporated herein by reference.
Format 0: DCI Format 0 is used for the transmission of resource grants for the PUSCH, using single-antenna port transmissions in uplink transmission mode 1 or 2.
Format 1: DCI Format 1 is used for the transmission of resource assignments for single codeword PDSCH transmissions (downlink transmission modes 1, 2 and 7).
Format 1A: DCI Format 1A is used for compact signaling of resource assignments for single codeword PDSCH transmissions, and for allocating a dedicated preamble signature to a mobile terminal for contention-free random access.
Format 1B: DCI Format 1B is used for compact signaling of resource assignments for PDSCH transmissions using closed loop precoding with rank-1 transmission (downlink transmission mode 6). The information transmitted is the same as in Format 1A, but with the addition of an indicator of the precoding vector applied for the PDSCH transmission.Format 1C: DCI Format 1C is used for very compact transmission of PDSCH assignments. When format 1C is used, the PDSCH transmission is constrained to using QPSK modulation. This is used, for example, for signaling paging messages and broadcast system information messages.Format 1D: DCI Format 1D is used for compact signaling of resource assignments for PDSCH transmission using multi-user MIMO. The information transmitted is the same as in Format 1B, but instead of one of the bits of the precoding vector indicators, there is a single bit to indicate whether a power offset is applied to the data symbols. This feature is needed to show whether or not the transmission power is shared between two UEs. Future versions of LTE may extend this to the case of power sharing between larger numbers of UEs.Format 2: DCI Format 2 is used for the transmission of resource assignments for PDSCH for closed-loop MIMO operation.Format 2A: DCI Format 2A is used for the transmission of resource assignments for PDSCH for open-loop MIMO operation. The information transmitted is the same as for Format 2, except that if the eNodeB has two transmit antenna ports, there is no precoding information, and for four antenna ports two bits are used to indicate the transmission rank.Format 2B: Introduced in Release 9 and is used for the transmission of resource assignments for PDSCH for dual-layer beamforming.Format 2C: Introduced in Release 10 and is used for the transmission of resource assignments for PDSCH for closed-loop single-user or multi-user MIMO operation with up to 8 layers.Format 2D: has been introduced in Release 11 and is used for up to 8 layer transmissions; mainly used for COMP (Cooperative Multipoint).Format 3 and 3A: DCI formats 3 and 3A are used for the transmission of power control commands for PUCCH and PUSCH with 2-bit or 1-bit power adjustments respectively. These DCI formats contain individual power control commands for a group of UEs.Format 4: DCI format 4 is used for the scheduling of the PUSCH, using closed-loop spatial multiplexing transmissions in uplink transmission mode 2.
The following table gives an overview of some available DCI formats and the typical number of bits, assuming for illustration purposes a system bandwidth of 50 RBs and four antennas at the eNodeB. The number of bits indicated in the right column include the bits for the CRC of the particular DCI.
TABLEDCI FormatsNumberof bitsDCIincludingformatPurposeCRC0PUSCH grants431PDSCH assignments with a single codeword471APDSCH assignments using a compact format431BPDSCH assignments for rank-1 transmission461CPDSCH assignments using a very compact format291DPDSCH assignments for multi-user MIMO462PDSCH assignments for closed-loop MIMO62operation2APDSCH assignments for open-loop58MIMO operation2BPDSCH assignments for dual-layer beamforming572CPDSCH assignments for closed-loop single-user or58multiuser MIMO operation2DPDSCH assignments for closed-loop single-61user or multi-user MIMO operation,COMP3Transmit Power Control (TPC) commands for43multiple users for PUCCH and PUSCH with 2-bitpower adjustments3ATransmit Power Control (TPC) commands for43multiple users for PUCCH and PUSCH with 1-bitpower adjustments4PUSCH grants52
In order that the UE can identify whether it has received a PDCCH transmission correctly, error detection is provided by means of a 16-bit CRC appended to each PDCCH (i.e. DCI). Furthermore, it is necessary that the UE can identify which PDCCH(s) are intended for it. This could in theory be achieved by adding an identifier to the PDCCH payload; however, it turns out to be more efficient to scramble the CRC with the “UE identity”, which saves the additional overhead. The CRC may be calculated and scrambled as defined in detail by 3GPP in TS 36.212, Section 5.3.3.2 “CRC attachment”, incorporated hereby by reference. The section describes how error detection is provided on DCI transmissions through a Cyclic Redundancy Check (CRC). A brief summary is given below.
The entire payload is used to calculate the CRC parity bits. The parity bits are computed and attached. In the case where UE transmit antenna selection is not configured or applicable, after attachment, the CRC parity bits are scrambled with the corresponding RNTI.
The scrambling may further depend on the UE transmit antenna selection, as apparent from TS 36.212. In the case where UE transmit antenna selection is configured and applicable, after attachment, the CRC parity bits are scrambled with an antenna selection mask and the corresponding RNTI. As in both cases the RNTI is involved in the scrambling operation, for simplicity and without loss of generality the following description of the embodiments simply refers to the CRC being scrambled (and descrambled, as applicable) with an RNTI, which should therefore be understood as notwithstanding e.g. a further element in the scrambling process such as an antenna selection mask.
Correspondingly, the UE descrambles the CRC by applying the “UE identity” and, if no CRC error is detected, the UE determines that PDCCH carries its control information intended for itself. The terminology of “masking” and “de-masking” is used as well, for the above-described process of scrambling a CRC with an identity.
The “UE identity” mentioned above with which the CRC of the DCI may be scrambled can also be a SI-RNTI (System Information Radio Network Temporary Identifier), which is not a “UE identity” as such, but rather an identifier associated with the type of information that is indicated and transmitted, in this case the system information. The SI-RNTI is usually fixed in the specification and thus known a priori to all UEs.
There are various types of RNTIs that are used for different purposes. The following tables taken from 3GPP 36.321 Chapter 7.1 shall give an overview of the various 16-bits RNTIs and their usages.
TABLERNTIsValue(hexa-decimal)RNTI0000N/A0001-003CRA-RNTI, C-RNTI, Semi-Persistent SchedulingC-RNTI, Temporary C-RNTI, TPC-PUCCH-RNTI andTPC-PUSCH-RNTI (see note)003D-FFF3C-RNTI, Semi-Persistent Scheduling C-RNTI,Temporary C-RNTI, TPC-PUCCH-RNTI andTPC-PUSCH-RNTIFFF4-FFFCReserved for future useFFFDM-RNTIFFFEP-RNTIFFFFSI-RNTIPhysical Downlink Control Channel (PDCCH) and Physical Downlink Shared Channel (PDSCH)
The physical downlink control channel (PDCCH) carries e.g. scheduling grants for allocating resources for downlink or uplink data transmission. Multiple PDCCHs can be transmitted in a subframe.
The PDCCH for the user equipments is transmitted on the first NsymbPDCCH OFDM symbols (usually either 1, 2 or 3 OFDM symbols as indicated by the PCFICH, in exceptional cases either 2, 3, or 4 OFDM symbols as indicated by the PCFICH) within a subframe, extending over the entire system bandwidth; the system bandwidth is typically equivalent to the span of a cell or component carrier. The region occupied by the first NsymbPDCCH OFDM symbols in the time domain and the NRBDL×NscRB subcarriers in the frequency domain is also referred to as PDCCH region or control channel region. The remaining NsymbPDSCH=2·NsymbDL−NsymbPDCCH OFDM symbols in the time domain on the NRBDL×NscRB subcarriers in the frequency domain is referred to as the PDSCH region or shared channel region (see below).
For a downlink grant (i.e. resource assignment) on the physical downlink shared channel (PDSCH), the PDCCH assigns a PDSCH resource for (user) data within the same subframe. The PDCCH control channel region within a subframe consists of a set of CCE where the total number of CCEs in the control region of subframe is distributed throughout time and frequency control resource. Multiple CCEs can be combined to effectively reduce the coding rate of the control channel. CCEs are combined in a predetermined manner using a tree structure to achieve different coding rate.
On a transport channel level, the information transmitted via the PDCCH is also referred to as L1/L2 control signaling (for details on L1/L2 control signaling see above).
There is a particular predefined timing relation between uplink resource assignments received in a subframe and the corresponding uplink transmission in PUSCH. Details are given in TS 36.213 v11.1.0 “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer procedures (Release 11)” Chapter 8.0 “UE procedure for transmitting the physical uplink shared channel” incorporated herewith by reference.
In particular, Table 8-2 of TS 36.213 which is reproduced in FIG. 7 defines the parameter k for the TDD configurations 0-6, where k indicates the positive offset of the target of an uplink resource allocation received in a subframe; for TDD configuration 0 there is additional definition of the timing for uplink subframes 3 and 8, omitted herewith for simplicity. For instance, the parameter k is 6 for subframe 1 of TDD configuration 1, meaning that an uplink resource allocation received in subframe 1 of TDD configuration 1 is intended for subframe 1+6=7 of TDD configuration 1, which indeed is an uplink subframe, etc.
Hybrid ARQ Schemes
A common technique for error detection and correction in packet transmission systems over unreliable channels is called hybrid Automatic Repeat request (HARQ). Hybrid ARQ is a combination of Forward Error Correction (FEC) and ARQ.
If a FEC encoded packet is transmitted and the receiver fails to decode the packet correctly (errors are usually checked by a CRC (Cyclic Redundancy Check)), the receiver requests a retransmission of the packet. Generally (and throughout this document) the transmission of additional information is called “retransmission (of a packet)”, although this retransmission does not necessarily mean a transmission of the same encoded information, but could also mean the transmission of any information belonging to the packet (e.g. additional redundancy information).
Depending on the information (generally code-bits/symbols), of which the transmission is composed, and depending on how the receiver processes the information, the following Hybrid ARQ schemes are defined:
In Type I HARQ schemes, the information of the encoded packet is discarded and a retransmission is requested, if the receiver fails to decode a packet correctly. This implies that all transmissions are decoded separately. Generally, retransmissions contain identical information (code-bits/symbols) to the initial transmission.
In Type II HARQ schemes, a retransmission is requested, if the receiver fails to decode a packet correctly, where the receiver stores the information of the (erroneously received) encoded packet as soft information (soft-bits/symbols). This implies that a soft-buffer is required at the receiver. Retransmissions can be composed out of identical, partly identical or non-identical information (code-bits/symbols) according to the same packet as earlier transmissions. When receiving a retransmission the receiver combines the stored information from the soft-buffer and the currently received information and tries to decode the packet based on the combined information. (The receiver can also try to decode the transmission individually, however generally performance increases when combining transmissions.) The combining of transmissions refers to so-called soft-combining, where multiple received code-bits/symbols are likelihood combined and solely received code-bits/symbols are code combined. Common methods for soft-combining are Maximum Ratio Combining (MRC) of received modulation symbols and log-likelihood-ratio (LLR) combining (LLR combing only works for code-bits).
Type II schemes are more sophisticated than Type I schemes, since the probability for correct reception of a packet increases with every received retransmission. This increase comes at the cost of a required hybrid ARQ soft-buffer at the receiver. This scheme can be used to perform dynamic link adaptation by controlling the amount of information to be retransmitted. E.g. if the receiver detects that decoding has been “almost” successful, it can request only a small piece of information for the next retransmission (smaller number of code-bits/symbols than in previous transmission) to be transmitted. In this case it might happen that it is even theoretically not possible to decode the packet correctly by only considering this retransmission by itself (non-self-decodable retransmissions).
Type III HARQ schemes may be considered a subset of Type II schemes: In addition to the requirements of a Type II scheme each transmission in a Type III scheme must be self-decodable.
Synchronous HARQ means that the re-transmissions of HARQ blocks occur at pre-defined periodic intervals. Hence, no explicit signaling is required to indicate to the receiver the retransmission schedule.
Asynchronous HARQ offers the flexibility of scheduling re-transmissions based on air interface conditions. In this case some identification of the HARQ process needs to be signaled in order to allow for a correct combining and protocol operation. In 3GPP LTE systems, HARQ operations with eight processes are used. The HARQ protocol operation for downlink data transmission will be similar or even identical to HSDPA.
In uplink HARQ protocol operation there are two different options on how to schedule a retransmission. Retransmissions are either “scheduled” by a NACK (also referred to as a synchronous non-adaptive retransmission) or are explicitly scheduled by the network by transmitting a PDCCH (also referred to as synchronous adaptive retransmissions). In case of a synchronous non-adaptive retransmission the retransmission will use the same parameters as the previous uplink transmission, i.e. the retransmission will be signaled on the same physical channel resources, respectively uses the same modulation scheme/transport format.
Since synchronous adaptive retransmissions are explicitly scheduled via PDCCH, the eNodeB has the possibility to change certain parameters for the retransmission. A retransmission could be for example scheduled on a different frequency resource in order to avoid fragmentation in the uplink, or eNodeB could change the modulation scheme or alternatively indicate to the user equipment what redundancy version to use for the retransmission. It should be noted that the HARQ feedback (ACK/NACK) and PDCCH signaling occurs at the same timing. Therefore the user equipment only needs to check once whether a synchronous non-adaptive retransmission is triggered (i.e. only a NACK is received) or whether eNode B requests a synchronous adaptive retransmission (i.e. PDCCH is signaled).
HARQ and Control Signaling for TDD Operation
As explained above, transmission of downlink or uplink data with HARQ requires that ACKnowledgements (ACK or Negative ACK) be sent in the opposite direction to inform the transmitting side of the success or failure of the packet reception.
In case of FDD operation, acknowledgement indicators related to data transmission in a subframe n are transmitted in the opposite direction during subframe n+4, such that a one-to-one synchronous mapping exists between the instant at which the transport is transmitted and its corresponding acknowledgment. However, in the case of TDD operation, subframes are designated on a cell-specific basis as uplink or downlink or special (see next chapter), thereby constraining the times at which resource grants, data transmissions, acknowledgments and retransmissions can be sent in their respective directions. The LTE design for TDD therefore supports grouped ACK/NACK transmission to carry multiple acknowledgements within one subframe.
For uplink HARQ, the sending (in one downlink subframe) of multiple acknowledgements on the Physical Hybrid ARQ Indicator CHannel (PHICH) is not problematic since, when viewed from the eNodeB, this is not significantly different from the case in which single acknowledgements are sent simultaneously to multiple UEs. However, for downlink HARQ, if the asymmetry is downlink-biased, the uplink control signaling (PUCCH) formats of FDD are insufficient to carry the additional ACK/NACK information. Each of the TDD subframe configurations in LTE (see below, and FIG. 5) has its own such mapping predefined between downlink and uplink subframes for HARQ purposes, with the mapping being designed to achieve a balance between minimization of acknowledgment delay and an even distribution of ACK/NACKs across the available uplink subframes. Further details are provided in TS 36.213 v11.1.0 “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer procedures (Release 11)” Chapter 7.3 incorporated herewith by reference.
TS 36.213 v11.1.0 “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer procedures (Release 11)” Chapter 10.1.3, incorporated herein by reference explains the TDD HARQ-ACK feedback procedure.
Table 10.1.3-1 of TS 36.213 which is reproduced in FIG. 6 gives the downlink association set index for the ACK/NACK/DTX responses for the subframes of a radio frame, wherein the number in the boxes for the TDD configurations indicates the negative offset of the subframe which HARQ feedback is transported in said subframe. For instance, subframe 9 for TDD configuration 0 transports the HARQ feedback of subframe 9−4=5; subframe 5 of TDD configuration 0 being indeed a downlink subframe (see FIG. 5).
In HARQ operation, the eNB can transmit different coded version from the original TB in retransmissions so that the UE can employ incremental redundancy (IR) combining [8] to get additional coding gain over the combining gain. However in realistic systems, it is possible that the eNB transmits a TB to one specific UE on one resource segment, but the UE can not detect the data transmission due to DL control information lost. In this case, IR combining will lead to very poor performance for decoding the retransmissions because the systematic data has not been available at the UE. To mitigate this problem the UE should feed back a third state, namely discontinuous transmission (DTX) feedback, to indicate that no TB is detected on the associated resource segment (which is different from NACK indicating the decoding failure).
Time Division Duplex—TDD
LTE can operate in Frequency-Division-Duplex (FDD) and Time-Division-Duplex (TDD) modes in a harmonized framework, designed also to support the evolution of TD-SCDMA (Time-Division Synchronous Code Division Multiple Access). TDD separates the uplink and downlink transmissions in the time domain, while the frequency may stay the same.
The term “duplex” refers to bidirectional communication between two devices, distinct from unidirectional communication. In the bidirectional case, transmissions over the link in each direction may take place at the same time (“full duplex”) or at mutually exclusive times (“half duplex”).
For TDD in the unpaired radio spectrum, the basic structure of RBs and REs is depicted in FIG. 4, but only a subset of the subframes of a radio frame are available for downlink transmissions; the remaining subframes are used for uplink transmissions, or for special subframes. Special subframes are important to allow uplink transmission timings to be advanced, so as to make sure that transmitted signals from the UEs (i.e. uplink) arrive roughly at the same time at the eNodeB. Since the signal propagation delay is related to the distance between transmitter and receiver (neglecting reflection and other similar effects), this means that a signal transmitted by a UE near the eNodeB travels for a short time than the signals transmitted by a UE far from the eNodeB. In order to arrive at the same time, the far UE has to transmit its signal earlier than the near UE, which is solved by the so-called “timing advance” procedure in 3GPP systems.
In TDD this has the additional circumstance that the transmission and reception occur on the same carrier frequency, i.e. downlink and uplink need to be duplexed in time domain. While a UE far from the eNodeB needs to start uplink transmission earlier than the near UE, conversely, a downlink signal is received by a near UE earlier than by the far UE. In order to be able to switch the circuitry from DL reception to UL transmission, guard time is defined in the special subframe. To additionally take care of the timing advance problem, the guard time for a far UE needs to be longer than for a near UE.
This TDD structure is known as “Frame Structure Type 2” in 3GPP LTE Release 8 and later, of which seven different uplink-downlink configurations are defined, which allow a variety of downlink-uplink ratios and switching periodicities. FIG. 5 illustrates the Table with the 7 different TDD uplink-downlink configurations, indexed from 0-6, where “D” shall indicate a downlink subframe, “U” an uplink subframe and “S” a special subframe. As can be seen therefrom, the seven available TDD uplink-downlink configurations can provide between 40% and 90% of downlink subframes (when, for simplicity, counting a special subframe as a downlink subframe, since part of such a subframe is available for downlink transmission).
FIG. 5 shows the frame structure type 2, particularly for a 5 ms switch-point periodicity, i.e. for TDD configurations 0, 1, 2 and 6.
FIG. 8 illustrates a radio frame, being 10 ms in length, and the corresponding two half-frames of 5 ms each. The radio frame consists of 10 subframes with each 1 ms, where each of the subframes is assigned the type of uplink, downlink or special, as defined by one of the Uplink-downlink configurations according to the table of FIG. 5.
As can be appreciated from FIG. 5, subframe #1 is always a Special subframe, and subframe #6 is a Special subframe for TDD configurations 0, 1, 2 and 6; for TDD configurations 3, 4 and 5, subframe #6 is destined for downlink. Special subframes include three fields: DwPTS (Downlink Pilot Time Slot), the GP (Guard Period) and UpPTS (Uplink Pilot Time Slot). The following Table shows information on the special subframe and in particular lists the lengths of DwPTS (Downlink Pilot Time Slot), the GP (Guard Period) and of UpPTS (Uplink Pilot Time Slot) as a multiple of the sample time Ts=(1/30720) ms as defined for 3GPP LTE Release 11.
TABLEspecial subframe configurations, Frame Structure Type 2Normal cyclic prefix in downlinkExtended cyclic prefix in downlinkUpPTSUpPTSSpecialNormalExtendedNormalExtendedsubframecyclic prefixcyclic prefixcyclic prefixcyclic prefixconfigurationDwPTSin uplinkin uplinkDwPTSin uplinkin uplink0 6592 · Ts2192 · Ts2560 · Ts 7680 · Ts2192 · Ts2560 · Ts119760 · Ts20480 · Ts221952 · Ts23040 · Ts324144 · Ts25600 · Ts426336 · Ts 7680 · Ts4384 · Ts5120 · Ts5 6592 · Ts4384 · Ts5120 · Ts20480 · Ts619760 · Ts23040 · Ts721952 · Ts12800 · Ts824144 · Ts———913168 · Ts———
The TDD configuration applied in the system has an impact on many operations performed at the mobile station and base station, such as radio resource management (RRM) measurements, channel state information (CSI) measurements, channel estimations, PDCCH detection and HARQ timings.
In particular, the UE reads the system information to learn about the TDD configuration in its current cell, i.e. which subframe to monitor for measurement, for CSI measure and report, for time domain filtering to get channel estimation, for PDCCH detection, or for UL/DL ACK/NACK feedback.
Shortcoming of Current Semi-Static TDD UL/DL Configuration Scheme
The current mechanism for adapting UL-DL allocation is based on the system information acquisition procedure or the system information change procedure, where the particular UL-DL TDD configuration is indicated by a SIB, in this case/specifically by the TDD-config parameter in SIB1 (for details on the broadcast of system information, 3GPP TS 25.331, “Radio Resource Control (RRC)”, version 6.7.0, section 8.1.1, incorporated herein by reference).
In the system information change procedure as specified in LTE Release 8, the supported time scale for a TDD UL/DL re-configuration is every 640 ms or longer. When re-using the ETWS (Earthquake and Tsunami Warning System), the supported time scale for UL-DL TDD re-configuration is every 320 ms or longer depending on the configured default paging cycle.
Nevertheless, the semi-static allocation of TDD UL/DL configuration may or may not reflect the instantaneous traffic situation. In case of rapid changes between an uplink-dominated to a downlink-dominated traffic situation, the system information change procedure is too slow for a dynamic TDD UL/DL re-configuration. Accordingly, the semi-static TDD UL/DL re-configuration is too slow to maximize the subframe utilization with respect to the instantaneous traffic situation.
In this respect, a dynamic TDD UL/DL re-configuration has been widely discussed in connection with LTE Release 12. The dynamic TDD UL/DL re-configuration is anticipated to adapt the TDD UL/DL configuration to the current traffic needs, for instance, to dynamically create more downlink subframes to increase the downlink bandwidth or to dynamically create more blanck uplink subframes in order to mitigate interference to communications e.g. in uplink or downlink or to/from a neighboring cell.
In particular, LTE Release 12 will support an explicit signaling for the dynamic TDD UL/DL re-configuration. For this purpose, various signaling mechanisms are currently discussed. These signaling mechanisms shall enable instantaneous distribution of information on the TDD UL/DL re-configuration within the communication system and shall allow the mobile station/base station to re-configure the TDD UL/DL configuration without delay.
It turns out that currently employed RRC signaling mechanisms cannot ensure short TDD UL/DL re-configuration intervals as required to meet the needs of a dynamic TDD UL/DL re-configuration. In this respect, it is currently expected that a DCI signaling mechanism will be defined to allow for the dynamic TDD UL/DL re-configuration. The re-configuration is assumed to be valid for at least one radio frame (i.e. 10 ms).
With the above defined system constraints, the dynamic TDD UL/DL re-configuration will have to overcome incompatibilities between DCI to PUSCH timing relations as well as PDSCH to HARQ-ACK timing relations that are defined for each of the TDD configurations.
As already described earlier, for each TDD configuration 0-6 a timing relation is defined between an uplink resource allocation (e.g. UL grant) in a DCI format 0/4 message and the corresponding target PUSCH transmission in an uplink subframe. Specifically, the DCI to PUSCH timing relation allows for target PUSCH transmissions to be scheduled that are overlapping radio frame boundaries. In other words, a PUSCH transmission and the relating DCI transmission may take place in different radio frames. For example, according to TDD configuration 6, a PUSCH transmission in subframe 2 in one radio frame relates to a DCI transmission that has taken place in the previous radio frame.
Similarly, for each TDD configuration 0-6 a timing relation is defined between one or plural PDSCH transmissions and one or plural subsequent Hybrid ARQ-ACK transmissions. Also the PDSCH to HARQ-ACK timing relation allows for HARQ-ACK transmissions overlapping radio frame boundaries. In other words, a HARQ-ACK transmission and the relating PDSCH transmission may take place in different radio frames. For example, according to TDD configuration 5, HARQ-ACK transmissions in subframe 2 for one radio frame relates to PDSCH transmissions that have taken place in the previous two radio frames.
In this respect, for a TDD UL/DL re-configuration between subsequent subframes the application of the corresponding DCI to PUSCH timing relations does not allow for a continuous resource allocation of all supported uplink subframes. The inconsistencies in the uplink resource allocation shall be exemplified for the case where the UL grant is in a DCI transmission that is transmitted before the TDD re-configuration takes effect and the PUSCH transmission relating to the DCI transmission is scheduled after the TDD re-configuration takes effect.
Exemplarily, a TDD UL/DL re-configuration from TDD configuration 3 to TDD configuration 6 is illustrated in FIG. 9a. For each of the TDD configuration 3 and TDD configuration 6, the DCI to PUSCH timing relations are indicated by dash-dotted arrows. Accordingly, for allocation of a PUSCH transmission (i.e. uplink transmission) in a subframe which supports uplink transmissions, a DCI transmission relating to the respective PUSCH transmission is indicated as the origin of the dash-dotted arrow.
However, due to the TDD UL/DL re-configuration from TDD configuration 3 to TDD configuration 6, a PUSCH transmission in the subframe with index 24 is not possible. In particular, the TDD configuration 6, which is to be used after the TDD UL/DL re-configuration takes effect (i.e. from and including the subframe with the index 20 onward), does not, in the DCI to PUSCH timing relation of TDD configuration 6, allow for a DCI transmission that could result in PUSCH transmission in the subframe with index 24. In FIG. 9a, this can be seen by the absence of arrow(s) terminating at the PUSCH of subframe 24.
Even when assuming that PUSCH transmissions relating to DCI transmission before the TDD UL/DL re-configuration are to be carried out after the TDD UL/DL re-configuration, as for example indicated for the PUSCH transmission in the subframes with index 22 and 23, there is no possibility of a DCI transmission that would result in the scheduling of a PUSCH transmission in the subframe with index 24.
Another example for the TDD UL/DL re-configuration from the TDD configuration 0 to TDD configuration 6 is illustrated in FIG. 10. Also in this example, there is no possibility of a DCI transmission that would result in the scheduling of a PUSCH transmission in the subframe with index 24.
Consequently, due to the DCI to PUSCH timing relation being predefined for each TDD configuration, the uplink bandwidth cannot be immediately utilized after TDD UL/DL re-configuration.
Further exemplarily, a TDD UL/DL re-configuration from TDD configuration 3 to TDD configuration 6 is also illustrated in FIG. 9b. For each of the TDD configuration 3 and the TDD configuration 6 the PDSCH to HARQ-ACK timing relations are indicated by dash-dotted arrows. Accordingly, for HARQ-ACK transmissions in a subframe which supports uplink transmissions, PDSCH transmissions relating to the respective HARQ-ACK transmissions are indicated as the origin of the dash-dotted arrow.
However, due to the TDD UL/DL re-configuration from TDD configuration 3 to TDD configuration 6, a HARQ-ACK transmission for the PDSCH transmissions in the subframe with indexes 11, 17 and 18 is not possible. In particular, the TDD configuration 6, which is to be used after the TDD UL/DL re-configuration takes place (i.e. from and including the subframe with the index 20 onward), does not, in the PDSCH to HARQ-ACK timing relation of TDD configuration 6, allow for HARQ-ACK transmissions relating to the PDSCH transmissions in the subframe with indexes 11, 17 and 18.
Even when assuming, that HARQ-ACK transmissions relating to PDSCH transmissions before the TDD UL/DL re-configuration are to be carried out after the TDD UL/DL re-configuration, as for example indicated for the HARQ-ACK transmissions relating to the PDSCH transmission in the subframes with index 15, 16 and 19, there is no possibility of HARQ-ACK transmissions that would acknowledge the PDSCH transmissions in the subframe with indexes 11, 17 and 18.
Consequently, due to the PDSCH to HARQ-ACK timing relation being predefined for each TDD configuration, the allocated Hybrid ARQ functionality cannot be immediately utilized after TDD UL/DL re-configuration.
In recent 3GPP LTE meetings various approaches were discussed for TDD UL/DL re-configuration. Specifically, it was proposed to separately define reference configurations for the DCI to PUSCH timing relations as well as the PDSCH to HARQ-ACK timing relations that would have to be continuously applied after TDD UL/DL re-configuration. Exemplarily, even though SIB1 TDD configuration is operated an UE would continuously apply the timing relation specified in the newly defined reference configuration.
However, these approaches have the following drawbacks: Firstly, an additional higher layer configuration is required. Secondly, reference configuration timing relations would have to be applied even if they are not (e.g. no longer) required.
In the exemplary case of the SIB1 TDD configuration, this results in unnecessarily long delays for some HARQ-ACK transmissions, in an unnecessary long delays between DCI an PUSCH transmissions from some TDD configurations, and in an unnecessary bundling/multiplexing of HARQ-ACK transmissions into a few PUCCH subframes.